Chad Fowler, My Job Went to India (page 121)

-Chad Fowler, My Job Went To India, page 133.

-Chad Fowler in My Job Went To India, with the idea from Seth Godin (whose book is linked in the quote)

Chad starts off by explaining what can happen if you get too comfortable: Tiffany.



Not that Tiffany, this one:

Do you remember a pop star named Tiffany (no last name) from the 1980s? She was in the top of the top forty, and a constant sound on the radio back then. She enjoyed immense success, becoming for a short time a household name.
...
Apparently, if she tried, she didn't move fast enough to hold the affection -- or even the attention -- of her fans. When the tastes of the nation turned from bubble gum to grunge, Tiffany suddenly became obsolete.

(However, she's been making headway in changing that, as Chad notes in the book.)

The point remains: you need to stay sharp. You cannot sit back and become complacent. Doing so in this industry can cause you to become extinct. And you'll probably be less famous than Tiffany or the Dodo. However, Didus ineptus may end up describing you well.

One thing you can do to stay sharp is recognize that, relative to information growth, your knowledge and skill levels are deteriorating rapidly. The consequences of what Gordon Moore observed in 1965 is that new possibilities for computation arise at an astounding rate.



That graph looks linear, so what's the big deal? Look at the left - it's logarithmic scale. That graph really looks like this:



That slope is so high it's almost negative.

You can't keep up with everything - but you can't afford to be late to the party when it comes to new trends in development either. If you were a desktop application programmer in 1992 and didn't look up until 2002, you'd probably say a few WTFs, and then start drowing in all the information you'd need to get started programming web applications. There's a lot to learn in new paradigms.

So you need to anticipate changes. You might not be able to jump the gun on the next big thing, but at worst you'll have augmented your arsenal, and you can stay close to other trends as well. Reading blogs and staying current in news and even journals can help you find new, up and coming developments. Thinking about how things will change and backing your hypotheses up with evidence from the literature can be a worthwhile activity in that regard.

Looking ahead and being explicit about your skill development can mean the difference between being blind or being visionary.

Know that you'll be obsolete. Don't accept obsolescence.

How do you deal with the pressure to stay current? What new things are you learning?

The point revolves around the fact that hitting the goal is short-lived, while the process of getting there takes up the bulk of the time. Therefore, wouldn't it be better to view the process as the goal itself, and make that the enjoyable part?

My view diverges from Chad's here. Whereas he implies that this observation is a better way to live generally, I tend to think it applies to particular people doing particular things. For instance, I might agree that, in general, the US is "a nation of people who are always focused on the outcome of a process," I wouldn't agree that it's "one of America's biggest problems" (Quoting Chad Fowler, pg. 156). Still, I might be more inclined to think that people's choice of goals doesn't line up with my own.

Regardless of the small divergence of our beliefs about the theory in general, I do agree that it works for software development. I'm not talking about doing software development as a means to achieve fame, fortune, girls, and cars (or just as a means to do something else with your life). For the production of software as a means to reach goals (including some where the path is the goal), I agree with Zed Shaw:

I've been saying for years that you can live a life involving code and hacking as a cultural phenomenon, but you can't live a life that only has code. You can work and make money doing web programming, but you can't make a life out if it. I try fill my mind and experiences with other shit, and then use code as one of many ways to express myself.

Those kinds of goals are rewarding long after you've achieved them. Memories last until you forget them, and you can drive that Ferrari convertible up and down the Pacific Coast Highway until it falls apart.





But if you're talking about finishing a project as the goal, then you're likely to put yourself in a lot of pain during the journey.

Back to the software development example, it's easy to get wrapped up in the delivery of the code you are creating. Your customer needs a web application up, and you focus on finishing that application. But, a living application is never "done." One release leads to the next. Too much focus on the end product distracts us from the real deliverable: the sustainable development of a new entity.

Focusing on the ending makes you forget to make the process good. And, bad processes create bad products. The product might meet its minimum requirements, but its insides will be ugly. You've optimized for the short-term end goal -- not for the inevitable, ongoing, future of the product's development. Not only do bad processes make bad products, but bad products make bad processes. Once you have one of these products that is messy inside, your processes adapt around it. Your product's broken windows lead to broken windows in your process. It's a vicious cycle.

Sound familiar?

It does to me. A focus on a ridiculously short promised delivery date leads to no tests leads to coupled code modules and "quick and dirty" hacks in the code. That leads to an inability to test and more hacks in maintenance. And the cycle continues.

Wouldn't it be better to treat the process of making applications as the goal to be enjoyed, rather than masochistically torturing yourself?



What's your experience like? Are you more likely to treat the end as the goal or the path? Which works better for you?

To be fair, it may be more enjoyable, but it might not be as profitable - at least that's what Chad Fowler talks about in this week's chapter from My Job Went to India, "Make Yourself a Map."

Staying sharp is hard to do. It's easy to get into "maintenance mode," becoming comfortable with where you're at, and staying there. While maintaining your health may be a fine thing to do, simply maintaining your current skill set means you'll become the next Javasaurus. By that I don't mean you'll be big, bloated, and intimidating. I mean when all you know is Java the language, and Java's no longer the language du jour, you'll go the way of the dinosaur (to borrow an often used cliché). When it comes to technological matters, you fall behind if you're not actively keeping up.



Keeping a daily to weekly plan has helped me become more productive. I even tried to create a longer-term map of where I'd like to be by years end, along with various things I'd like to accomplish (which has only been semi-successful, if true be told). But one thing I've never done is create a map the way Chad's talking about here (pgs 151-152):

Your personal product road map is what you use to tell whether you've moved. When you're going to the same office day in and day out, working on a lot of the same things, the scenery around you doesn't change. You need to throw out some markers that you can see in the distance, so you'll know that you've actually moved when you get to them. Your product "features" are these markers.

Unless you really lay it out and make a plan, you won't be able to see beyond the next blip on the horizon. In Chapters 2 and 3, you discovered how to be intentional about your choice of career path and how to invest in our professional selves. Though I focused on what seemed like a onetime choice of what to invest in, each choice should be part of a greater whole. Thinking of each new set of knowledge or capability as equivalent to a single feature in an application puts it in context really well. An application with one feature isn't much of an application.

What's more, an application with a bunch of features that aren't cohesive is going to confuse its users... A personal product road map can not only help you stay on track, constantly evolving, but it can also show you the bigger picture of what you have to offer...

While it's definitely OK to learn diverse skills -- it expands your thinking -- it's also a good idea to think about the story your skill set tells. (Bold emphasis applied by me.)

For a couple of vacations I've taken in the past, I spun a pen on a map and drove to where it pointed the same night (up to 15 hours away). So far, my career map looks the same: as if a monkey tossed darts at a bunch of options and I decided to follow whatever the darts landed on.



I'm mostly a web developer - in the sense that I derive most of my income, write most of my code, and spend most of my time writing code that will in some way show up on the web or affect something that will show up on the web.

But I am also interested in, and spend significant time programming and studying artificial intelligence and machine learning, bioinformatics, and game development. I'm also interested in business for the sake of business (though I only occasionally write about it here). I enjoy writing desktop software as well (though I rarely have done so).

AI and game development dovetail nicely with each other. There are a lot of similarities between and overlap in algorithms for bioinformatics and AI. But short of creating a bioinformatics game on the web, it's hard to imagine where all these skills and interests intersect.

Perhaps it would be better for me to try and create a coherent picture out of the skills I choose to learn. But I rather enjoy having my hands and mind roam freely.

How's your skill set? Is it too focused, where you might need some breadth, or do you have a bit of a programmer dissociative identity, where some cohesion could take you a long way?

The theme in this part of Chad Fowler's MJWTI is reiterated here: don't rest on your laurels. You have to be proactive about keeping your skills up-to-date. Paying attention to the market, and acting on the knowledge that's available regarding the "in" technologies will help you do that.

Chad tells a hypothetical story about the demise of Java:

What if, for example, Sun Microsystems started showing signs of going under? Java isn't an open standard. It is dictated and developed by Sun. At any point, a dying Sun might attempt to suddenly make its language and virtual machine into a last-minute profit center. They might introduce incompatible changes or suddenly change the license restrictions of Java, causing an industry panic followed by a mass exodus.

With your head in your monitor coding, you might not even hear about something like this until it was too late.

What if you're a Flash guru and Microsoft's Silverlight comes pre-installed on 98% of the computers in the world as Adobe's Flash loses the support of management? Will Flash maintain it's market share? What if Adobe drops support for ColdFusion? Will the open source world carry the torch? What if Microsoft decided .NET isn't going to cut it for the next generation of programming paradigms, and scraps it? Will your skills in .NET be valuable for as long as your career keeps you working? What if management decides they want to standardize on a cross-virtual-machine dynamic functional language called Fan, and they want to keep the familiar curly-brace-and-semi-colon syntax? Will you still be using Ruby, Python, or Perl at your day job?

Are you willing to take those chances?

The most likely scenario is that these technologies will continue to exist, as they slowly fade away into the Next Big Things. As Chad notes,

Even more likely is that, comfortable in your current job with your current set of skills, you might remain blissfully ignorant of the Next Big Thing as it rolls in. Ten years ago, you would have been surprised to find out just how big object-oriented languages with garbage collection would become. But, there were definitely signs if you were watching.

Ten years ago we couldn't have done the work with DNA and large genomes that we can do today. More interesting problems (in bioinformatics and elsewhere) are able to be solved by more people just because of increases in memory, processor speed, disk space, and number of processors. What are you doing to learn about concurrency? What are you doing to learn about optimizations you can make? When constant-factor reductions in processing time save days to weeks of computations, it's not premature to make them.

Are you watching?

In fact, some people wear them when they know they'll be eating a lot, just for that purpose.

It's hard enough to know when you're getting fat - after all, you're you and it's a slow process, so you wouldn't notice unless your pants got tighter or you were reviewing your weight on the scale regularly.



It's even harder to notice when you're wearing sweatpants. You can go for years - growing and growing ...



And before you know it, you've not just beat anorexia, you've pwned it.

As with the other chapters in this section of My Job Went To India, "That Fat Man in the Mirror" boils down to refusing to let yourself become comfortable in where you're at personally (not geographically) as a programmer. In this case, you need to put away your programming skill fatpants, and periodically review your skills. Take an inventory. Better yet, have someone else evaluate you. Sweats may allow for growth, but it's not the good kind.

An easy way to measure your progress is to use a trusted third party. A mentor or a close colleague doesn't live in your head with you and can help give you a more objective look at where you stand. You might discuss your abilities as a software developer, project leader, communicator, team member, or any other facet of the total package that makes you who you are. (Chad Fowler, pgs. 155-156 of My Job Went to India)

If you're a bit uncomfortable asking someone to help in that way, you should make use of review-time at your company (if there's such a thing where you're at).

If your company has such processes in place already, don't write them off as HR nonsense. Take them seriously and make good come out of them.

Keep it written down and revise and review often, Chad says.

That sounds like solid advice to me. I got started with some goals earlier in the year, and had planned to periodically review them here on the weblog. But that hasn't happened, so it's something which I need to put more effort into.

Don't get be lethargic about your skills. Instead, take off the fatpants and actively evaluate where you're at and where you need to be. Get some feedback. Otherwise, some day in the future you may end up wondering to yourself, "how did I lose my edge?"

Do you review yourself periodically? Have you used the reviews to become better?

In My Job Went to India, Chad Fowler's final bit of advice for keeping sharp and up to date urges us to not allow ourselves the mental security blanket of value rigidity - or the mental crutch, as it often turns out to be. You might not even be aware you're using one yet.

Chad tells the story of Novell's decline:

Many of us in the mid-1990s swore by Novell's NetWare platform when it came to providing ?le and print services in the enterprise. Novell was way ahead of its time with its directory services product, and those of us "in the know" were almost cocky in our criticism of competing technologies. Novell's product was enjoying a healthy majority in market share, and it was hard to imagine the tide turning.

No single event made it obvious that Novell was losing to Microsoft. Microsoft never made that magic Active Directory release that made us all say, "Wow! Drop NetWare!" But, Netware has slowly gone from bleeding- edge innovator to legacy technology. For many NetWare administrators, the water was boiling before they ever even realized the pot was warm.

By allowing yourself the comfort and ease of such a mental crutch, you're doomed to keep repeating what worked in the past, even if it's not the best solution today. Before you know it, your technology of choice is no longer the soup du jour, and you're stuck knowing nothing else.

Instead of blindly advocating your technology of choice -- no matter the absurdity of that solution in the situation -- have "stong opinions which are weakly held." Realize "it depends" is a valid answer to programming questions.

Don't be afraid of being a wishy-washy flip-flopping programmer. It may sink political careers, but it's an asset in technology.

Slaughter sacred cows.



What are your own monkey traps?

Side Note: Posted Thursday instead of Friday because I'm off to Lone Star Ruby Conference in the morning. Hit me up on twitter or contact me if you're going to be there.

• Communication bandwidth is lower when it's not face to face. Most will be done through email, so most of it will suck comparatively.
  
  
• Being in (often widely) different time zones means synchronous communication is limited to few overlapping hours of work. If you get stuck and need an answer, you stay stuck until you're in one of those overlaps. That sucks.
  
  
• Language and cultural barriers contribute to dysfunctional communication. You might need an accent to accent translator to desuckify things.
  
  
• Because of poor communication, we could find ourselves in situations where we don't know what each other is doing. That leads to duplicative work in some cases, and undone work in others. Which leads to more sucking for your team.
  
  

The bad news is that there's a lot of potential to suck. The good news is there's already a model for successful and unsuccessful geographically distributed projects: those of open source.

You can learn in the trenches by participating. You can find others' viewpoints on successes and failures by asking them directly, or by reviewing open source project case studies. Try to think about the differences and be creative with ways to address them.

Doing that means you'll be better equipped to cope with challenges inherent with outsourced development. And it puts you miles ahead of your bitchenmoaning colleagues who end up trying to subvert the outsourcing model.

It's pointless to fight it. You can try to change the world. Or, you could think of changing yourself. Luckily, it's fairly easy to turn this to your advantage: just show people that you care about them as humans, not just colleagues.

If I have to depend on someone to get something done for me or to deliver a piece of software that I have to successfully integrate with, I'm going to have much better luck if that person feels I respect them and if they respect me. Would you respect someone who wouldn't even bother to learn how to pronounce your name?
...
If you show your teammates that you are interested in them as people, you will form tighter bonds and, on the whole, do better work.

On the contrary, you could be an ass - perhaps without even realizing it:

As I got to know our team members in India, I often heard them say that I wasn't like the typical American manager. When I asked what they meant, those who felt comfortable enough would say, You actually take an interest in us. Most of you are just angry and short with us.

I had a fellow student at school say the same thing to me. He asked, "Are you natively American?" It was eye opening to think that he had been treated so poorly by other Americans that he had to ask me if I am one (I am.)

Incidentally, this is a tactic in getting anyone to like you generally, so if you have friends, you don't need to learn any new skills. In this case, it may be even easier because you know tons of things exist that you don't know about them: just pick a couple and ask about them. All Chad had to do was say "Hello, my name is Chad" in their native language. It's about making a small effort, that's all.

Meta
This week marks the end of the Save Your Job series, at least as far as following each chapter of Chad Fowler's book, My Job Went To India. Why? Well, because it's the last one in the book. I'll still post to that category as things come up, but it's not likely to be weekly.

This is a book that, in my opinion, is a must-read for software developers, and it's so short you can read it multiple times - to remind yourself as you slip back into old habits, or to reinvigorate interest in goals you set for yourself in times past.

In any case, I hope you've enjoyed the weekly series, and more than anything else, I hope you got something useful from it. It was useful to me!

While I thoroughly enjoyed Chad's book, I must say I'm glad to be done with the series. I've been wanting to free up some time to do some more technical things, like playing with my new Arduino Diecimila.

Keep watching.

(And don't ask me how sad it makes me feel that my favorite book as a kid has only a 240px image online. I need to find my copy and scan it.)

But just like its more enlightened brethren, tech support consists of troubleshooting. In fact, it should be the first line of defense to keep your coders coding and off the phone. Who wants them to man the phones? Certainly not the programmers. Certainly not management. Tech support is a cost center, not a customer service opportunity.

That's a lie of course. It's a bajillion times more likely that you'll sell to an existing customer than someone else¹. So why do we see such poor customer service? Especially in our own industry?

Perhaps when you have a virtual monopoly over a market like most cable companies or utilities in a given locale, you can afford to have poor customer service. The cable sphere seems to be opening up, what with satellite TV and internet and now AT&T and Verizon offering television and decent-to-good internet packages. Even still, AT&T's UVerse has its own problems, I've heard, and (at least personally) I've not witnessed the kind of customer service that competition promises with regards to cable TV and internet access.

Is tech support really that bad? Maybe it's not. There are some folks that have decent starting advice. Even if it's not How To, at least Some Ways is better than no ways.

The fact is we tend to treat support like a second class citizen. It's a position we want to fill with a minimum-wage worker (or less, if we can outsource it) who has no expertise, no clue, and doesn't care to learn the product since he can get a job in the fast food industry at about the same rate. And with no stress!

It makes it worse that we don't even want to take the time to train him, since it would take away from the productive code-writing time to do so.

The person we want to treat as an ape or worse always seems expendable. We treat them so. Should they be?



I say no. Not only am I a big fan of dogfooding, I feel like Fog Creek's giving customer service people a career path nowadays matches a lot of my ANSI artist peers' experiences from back in the day. Smart people start in support, and they can move themselves up in the organization to play more "key roles."

Bill puts on a headset, sits down, and answers the phone. "Hello, this is Microsoft Product Support, William speaking. How can I help you?"

Bill talks with the customer, collects the details of the problem, searches in the product support Knowledge Base, sifts through the search results, finds the solution, and patiently walks the customer through fixing the problem.

The customer is thrilled that William was able to fix the problem so quickly, and with such a pleasant attitude. Bill wraps up the call. "And thank you for using Microsoft products."

At no point did Bill identify himself as anything other than William. The customer had no idea that the product support engineer who took the call was none other than Bill Gates.

Like Bill.

I don't think it needs to be a full-time thing, but it certainly helps if programmers are their own support team. Like Bruce Johnson who posted that linked message, I work on a small team and can vouch: it's downright embarrassing to have to support our customers. I'm glad to do it, but when it happens, more than likely I've got to take blame for the problem I'm dealing with. You know how hard I try to make sure my code works as expected before I deploy it?

"OMG I'm sorry, that's my fault, I'll fix it for you right away." Can you get better support than that?

I'm not so sure I'd have tried that hard without the customer experience pushing me.

I think I've made my first point: that customer support is customer service is important to the health of your business. While I agree that tech support in the common use of the term is useful to shield your programmers from inane requests, I also recognize the value in having programmers take those calls from time-to-time.

Given that, I do in fact have some do's and do-not's with regards to support. The list here deals mostly with how to be a good support technician for your team, as opposed to the customer. Still, the customer is central to the theory. Although it does not make an exhaustive list, here are four contributions to The General Procedures For Troubleshooting:

1. After listening to the problem description, the first thing to do is recognize whether or not you can solve the problem while the customer is on the phone, or if anyone can. If you can, then do it. If you think only someone else can do it, and work for an organization that has multiple levels of live-support, then escalate it.
   
   If you don't think solving the problem is possible without escalating it to a level of support that won't get to it immediately, thank the customer for reporting the issue, let them know the problem is being worked on, and boogie on to step 2.
   
   
2. As support, the first thing you need to do before escalating the issue is confirm there is an issue, and do it with a test account, not the user's.
   
   It's ridiculous to ask for the user's credentials. Don't do it. If someone were to ask you, "What is your username and password?" what would you think? The average user isn't going to know your query is tantamount stupidity, but if you get someone who is slightly security-conscious, you're going to lose a customer. Hopefully, he's not a representative of your whale.
   
   If anyone found out that you're in the habit of asking users for their passwords, they can easily call anyone who uses your software and get in by just asking. Further, since many people use the same password for everything or many things, that person would also have access to your customers' other sensitive information, wherever it resides.
   
   You can point the blame at your stupid customer for using the same password everywhere they go all you want. You're being just as stupid by opening the door for that type of attack. Further, you should always try to recreate and fix the problem with as little inconvenience to the user as possible. That means doing it with test accounts as opposed to asking the user for theirs, or changing their information.
   
   Keep things simple for the user. Don't jump immediately to using their time to make things easier on the support team. Doing that is lazy at best, sloppy most of the time, and could result in disaster at worst.
   
   
3. After confirming the existence of the problem, provide the steps of how to reproduce it. Give some screen shots. If it's a web app, provide links. Don't constantly send and email and ask the higher levels about it. Doing so once or twice is one thing, but doing it for every request is a time-waster. Just send the email and the next level will get to it when they can. If they don't get to it within the acceptable time-frame for your organization, send a reminder. Include the boss if you need to. But don't do that prematurely (and that's another subject altogether).
   
   
4. Don't jump to conclusions about the source of the problem. Although Abby Fichtner wasn't speaking directly to support ...
   
   
   
   ... This is the opposite of my general approach. The parallel here is code : customer :: you : dumb². I've learned (even if through a bit of self-torture) that I should always look at the code first, if for no other reason than I don't want to be foolishly blaming others when I'm to blame. In the case of support, I've always hated the term "User Error," and that's what the tweet reminds me of.
   
   By framing it as an external problem, we miss an opportunity to teach the user how to use the product, or a chance to improve the product to make sure they can't use it "incorrectly."

What are your thoughts about tech support? What can you contribute to The General Procedures For Troubleshooting?


Notes:

1) I know this statistic, it's even intuitive, but I can't seem to find it online for free. Here's some apparently made-up stats to satisfy you. Go back to what you were reading.

2) "word1 : word2 :: word3 : word4" is SAT (and elsewhere) notation for the analogy "word1 is to word2 as word3 is to word4." See freesat1prep.com for a few examples.

Some links in this post are affiliate links. This message brought to you by the Federal Trade Commission.

My first job primarily used Cold Fusion. When I joined AOL Time Warner I gave up Cold Fusion for PHP. When I joined IAG I gave up PHP for C#. And so on. As you can see, I've never been too tied to a language. I've always been most interested in learning and growing. I love jobs that help me improve my skills.
...
I prefer jobs that allow me to learn new things. Think of it as job security -- I shouldn't ever be out-of-date when it comes to technology experience. Think of it as an investment -- everything I learn creates a broader range of experience that I can leverage for future projects or jobs. Think of it as experimenting -- by trying many different solutions I may find ways to combine them and innovate.

Programming in C for the first time seems to be a chore. There are many details about your Code you need to keep track of. And C doesn't even lend you much of a hand when programming. There are no iterators, memory management is done manually, and handling strings correctly is akin to walking through a minefield with a hood over your head. While on fire. And being chased by a pack of wild dogs.

But then the question still stays: "what should one learn next?". Algorithms, data structures, complexity, math... Learn the core abstracts, ideas, and skills that are language independent, and that transfer from one syntax to another. Learn the ability to learn. When a new opportunity with new technology comes along, you should be able to get over the learning curve fairly quickly.
...
So lets drop this obsession with learning to say "hello world" (or some more complicated version of essentially the same) in every programming language one can name. Lets also drop the idea of finding "one language to rule them all; and retire". Once we put the Science back in Computer Science, it wouldn't matter which language you'll end up using.

(A disclaimer for you: I read this book as a reviewer and haven't yet made the time to go through the finished product, so some of what I'm about to say may change. That said, I can only imagine that it got better before going to publication, so I don't expect anyone would be disappointed.)

The Passionate Programmer retains that status of being a must-read. It adds a few new chapters and removes a couple of others, but more importantly it changes the framing from the negative view of "save your job" to what My Job Went to India was always really about anyway: "creating a remarkable career in software development."

Here's what I had to say about it for the blurb:

Six short months before I read Chad's book, I was on the verge of changing careers. Through a series of accidents from November to May, I decided not only to stick with software development but to be passionate about it while striving to be great. With a healthy dose of inspiration, the book you're now holding served as a road map for achieving those goals.

It truly is an excellent map that helped me find my way from Quit Town to making the decision to be passionate about hacking and life in general, starting this blog, and striving to leave the realm of the unclean masses in our profession whose exploits we read about so often.

If you read MJWTI and understood the positive aspects of it, this book isn't that important since you know most of it already. I'd have purchased it anyway, but you may feel differently. That's Okay.

However, if you felt you'd be embarrassed if someone saw you holding the first version - or just haven't read it before - I strongly recommend picking up a copy of this version and going through it. Don't just read it though - apply it. At the end of every chunk of advice there is a list of activities that you can perform. Don't just gloss over them; make it a point to actually do some of them.

It's short enough to read through in one or two sittings. But there's enough content in there to keep you busy for a couple of years.

If you've read this book or the 1^st edition, what did you think about it? Am I overenthusiastic?

I look forward to covering the new chapters as time allows over the next few weeks. I hope you'll join me in the discussion.

He thinks many tasks are beneath him. He avoids them when possible and does them begrudgingly (and slowly) when not. He cherry-picks work that he thinks, even if subconciously, is in tune with his level and might get him closer to his goal of the next promotion.

That's the paragraph that hit home with me, because I used to be that developer. However, I never looked at it as a way to get ahead (being in such a small company and all). But, I did justify it by saying things to myself like "this is beneath my skill level - I don't want to waste money they are paying me by wasting time on these mundane tasks that could be done by a monkey."

Even until recently, I took this attitude in some regard. So much so, that during our recent SWOT analysis, I brought it up as a weakness against myself, and resolved to take the opposite approach. Now, I find ways to automate many of those menial tasks, and in general just do what the job requires, without regard to the prestige of task at hand.

If you want me to follow an elephant around with a shovel, I'll do it, and I'll try to be the best damn shit-shoveler you've ever seen.

Know anyone like the horror-story? Anyone who has overcome that superiority complex?

To remedy this, Chad says it's easy to ask your manager how you can help. When you help your manager, he helps his, and so on, all the way up the food chain. In doing that, you can be sure that your work is aligned with the goals of the business, and it doesn't hurt to keep the man happy "who holds the keys to your career (in your present company, at least)."

Of all the chapters thus far in the book, this was the least inspirational for me. That's not any fault of Chad's but more because of the fact that I've always worked at small companies. Therefore, I've always been fortunate enough to have close relationships with the people in power positions, and I've been much more of a mind reader because of it.

However, that doesn't mean I still can't ask what I can do to help us reach our goals, and what those goals are. So earlier this week, after reading the chapter, I was inspired to do just that. Try it out and see if it works for you, especially if you're at a larger company. Perhaps you can discuss longer term objectives over lunch.

You've got a related story? I'd love to hear about it in the comments below.

I think you just have to make the decision to be passionate. Wake up in the morning and think about how lucky you are. Decide to enjoy the day, and to enjoy what you do. But you can do better.

Think about what drew you to the profession in the first place, and try to get a job doing that. If you can't get one in a timely fashion, try to get a job doing something similar and spend your free time working on side projects that interest you. That's a lot of what I'm doing.

For me, it is learning new things and gaming that I enjoy most. So, I spend a lot of time doing that. I still have to do grunt work, but I get equal doses of fun stuff too - all the while I am expanding my skill set and enjoying most of it.

As far as the job search goes, I'd recommend networking with people. Visit the local User Groups, get involved in forums and mailing lists. Learn things and share them, and people will eventually come to you with jobs. Even though I like the computers, I've found that I really enjoy the relationships with people who also like computers. Before, I stayed locked in a room thinking and working by myself. Now, I venture out from time to time, and in addition, I have the online relationships I enjoy immensely.

Since you probably can't afford to live that long without a job, perhaps in the mean time you can go to a career fair at a local university or just use the search term "programming" and browse jobs until you find one that interests you.

I'd also read many different weblogs about programming to stay up to date on trends in the industry, as well as to receive solid advice that stands the test of time.

Just as importantly, take a look back at your own situation. Can you identify anything that may be causing your malaise? If so, can you remove it? It may be as simple as that.

To the rest of you: how do you maintain and find passion in your work when you seem to have lost it?

I work in an environment where it wouldn't benefit me to "tell the manager" about my daily hits. They know already. But you might want to make yours known. Obviously you don't want to be braggadocious about it, but don't keep it to yourself either.

I like to do more than one hit per day. One is the absolute minimum. I try to get an overview of what needs to be done during the week, and create a high level plan in my mind over the weekend. I'll set each day's tasks and the time I'll be working on them on the day before. Then, I stick to the plan.

Even when I don't finish a task in the time allotted, I can reschedule and finish it the next day. In this way, I'm always having small successes which keeps me motivated and moving along towards my goals.

We're not talking about just what has to be done - it's about going above and beyond that. Chad ends the chapter with the advice to make a list of the "nitpicky problems" you and your team face that waste a little time each day, and starting to do some work on those things. I've done some of that, but there's plenty left to do, and re-reading this chapter reminded me that I need to start scheduling those things as well.

Do you do anything similar?

The experiences discussed herein were valuable in their own right, but the challenge itself is rewarding as well. How often do we pause to reflect on what we've learned, and more importantly, how it has changed us? Because of that, I recommend you perform the exercise as well.

I freely admit that some of this isn't necessarily caused by my experiences with the language alone - but instead shaped by the languages and my experiences surrounding the times.

One last bit of administrata: Some of these memories are over a decade old, and therefore may bleed together and/or be unfactual. Please forgive the minor errors due to memory loss.


How QBASIC Made Me A Programmer

As I've said before, from the time I was very young, I had an interest in making games. I was enamored with my Atari 2600, and then later the NES. I also enjoyed a playground game with Donald Duck and Spelunker.

Before I was 10, I had a notepad with designs for my as-yet-unreleased blockbuster of a side-scrolling game that would run on my very own Super Sanola game console (I had the shell designed, not the electronics).

It was that intense interest in how to make a game that led me to inspect some of the source code Microsoft provided with QBASIC. After learning PRINT, INPUT, IF..THEN, and GOTO (and of course SomeLabel: to go to) I was ready to take a shot at my first text-based adventure game.

The game wasn't all that big - consisting of a few rooms, the NEWS directions, swinging of a sword against a few monsters, and keeping track of treasure and stats for everything - but it was a complete mess.

The experience with QBASIC taught me that, for any given program of sufficient complexity, you really only need three to four language constructs:

1. Input
2. Output
3. Conditional statements
4. Control structures

Even the control structures may not be necessary there. Why? Suppose you know a set of operations will be performed an unknown but arbitrary amount of times. Suppose also that it will be performed less than X number of times, where X is a known quantity smaller than infinity. Then you can simply write out X number of conditionals to cover all the cases. Not efficient, but not a requirement either.

Unfortunately, that experience and its lesson stuck with me for a while. (Hence, the title of this weblog.)

Side Note: The number of language constructs I mentioned that are necessary is not from a scientific source - just from the top of my head at the time I wrote it. If I'm wrong on the amount (be it too high or too low), I always appreciate corrections in the comments.


What ANSI Art taught me about programming

When I started making ANSI art, I was unaware of TheDraw. Instead, I opened up those .ans files I enjoyed looking at so much in MS-DOS Editor to see how it was done. A bunch of escape codes and blocks came together to produce a thing of visual beauty.



Since all I knew about were the escape codes and the blocks (alt-177, 178, 219-223 mostly), naturally I used the MS-DOS Editor to create my own art. The limitations of the medium were strangling, but that was what made it fun.

And I'm sure you can imagine the pain - worse than programming in an assembly language (at least for relatively small programs). Nevertheless, the experience taught me some valuable lessons:

• Even though we value people over tools, don't underestimate the value of a good tool. In fact, when attempting anything new to you, see if there's a tool that can help you. Back then, I was on local BBSs, and not the 1337 ones when I first started out. Now, the Internet is ubiquitous. We don't have an excuse anymore.
  
  
• I can now navigate through really bad code (and code that is limited by the language) a bit easier than I might otherwise have been able to do. I might have to do some experimenting to see what the symbols mean, but I imagine everyone would. And to be fair, I'm sure years of personally producing such crapcode also has something to do with my navigation abilities.
  
  
• Perhaps most importantly, it taught me the value of working in small chunks and taking baby steps. When you can't see the result of what you're doing, you've got to constantly check the results of the latest change, and most software systems are like that. Moreover, when you encounter something unexpected, an effective approach is to isolate the problem by isolating the code. In doing so, you can reproduce the problem and problem area, making the fix much easier.

The Middle Years (included for completeness' sake)

The middle years included exposure to Turbo Pascal, MASM, C, and C++, and some small experiences in other places as well. Although I learned many lessons, there are far too many to list here, and most are so small as to not be significant on their own. Therefore, they are uninteresting for the purposes of this post.

However, there were two lessons I learned from this time (but not during) that are significant:

1. Learn to compile your own $&*@%# programs (or, learn to fish instead of asking for them).
2. Stop being an arrogant know-it-all prick and admit you know nothing.

As you can tell, I was quite the cowboy coding young buck. I've tried to change that in recent years.


How ColdFusion made me a better programmer when I use Java

Although I've written a ton of bad code in ColdFusion, I've also written a couple of good lines here and there. I came into ColdFusion with the experiences I've related above this, and my early times with it definitely illustrate that fact. I cared nothing for small files, knew nothing of abstraction, and horrendous god-files were created as a result.

If you're a fan of Italian food, looking through my code would make your mouth water.

DRY principle? Forget about it. I still thought code reuse meant copy and paste.

Still, ColdFusion taught me one important aspect that got me started on the path to Object Oriented Enlightenment: Database access shouldn't require several lines of boilerplate code to execute one line of SQL.

Because of my experience with ColdFusion, I wrote my first reusable class in Java that took the boilerplating away, let me instantiate a single object, and use it for queries.


How Java taught me to write better programs in Ruby, C#, CF and others

It was around the time I started using Java quite a bit that I discovered Uncle Bob's Principles of OOD, so much of the improvement here is only indirectly related to Java.

Sure, I had heard about object oriented programming, but either I shrugged it off ("who needs that?") or didn't "get" it (or more likely, a combination of both).

Whatever it was, it took a couple of years of revisiting my own crapcode in ColdFusion and Java as a "professional" to tip me over the edge. I had to find a better way: Grad school here I come!

The better way was to find a new career. I was going to enter as a Political Scientist and drop programming altogether. I had seemingly lost all passion for the subject.

Fortunately for me now, the political science department wasn't accepting Spring entrance, so I decide to at least get started in computer science. Even more luckily, that first semester Venkat introduced me to the solution to many my problems, and got me excited about programming again.

I was using Java fairly heavily during all this time, so learning the principles behind OO in depth and in Java allowed me to extrapolate that for use in other languages. I focused on principles, not recipes.

On top of it all, Java taught me about unit testing with JUnit. Now, the first thing I look for when evaluating a language is a unit testing framework.


What Ruby taught me that the others didn't

My experience with Ruby over the last year or so has been invaluable. In particular, there are four lessons I've taken (or am in the process of taking):

• The importance of code as data, or higher-order functions, or first-order functions, or blocks or closures: After learning how to appropriately use yield, I really miss it when I'm using a language where it's lacking.
  
  
• There is value in viewing programming as the construction of lanugages, and DSLs are useful tools to have in your toolbox.
  
  
• Metaprogramming is OK. Before Ruby, I used metaprogramming very sparingly. Part of that is because I didn't understand it, and the other part is I didn't take the time to understand it because I had heard how slow it can make your programs.
  
  Needless to say, after seeing it in action in Ruby, I started using those features more extensively everywhere else. After seeing Rails, I very rarely write queries in ColdFusion - instead, I've got a component that takes care of it for me.
  
  
• Because of my interests in Java and Ruby, I've recently started browsing JRuby's source code and issue tracker. I'm not yet able to put into words what I'm learning, but that time will come with some more experience. In any case, I can't imagine that I'll learn nothing from the likes of Charlie Nutter, Ola Bini, Thomas Enebo, and others. Can you?

What's next?

Missing from my experience has been a functional language. Sure, I had a tiny bit of Lisp in college, but not enough to say I got anything out of it. So this year, I'm going to do something useful and not useful in Erlang. Perhaps next I'll go for Lisp. We'll see where time takes me after that.

That's been my journey. What's yours been like?

Now that I've written that post, I have a request for a post I'd like to see:

What have you learned from a non-programming-related discipline that's made you a better programmer?

We might be standing around waiting for a pot of coffee to brew, and I would talk about how great it would be if we had some new flexibility in our code that didn't exist before. If I said it often enough or with enough conviction, even though I hadn't really put it on the team's TO-DO list, Rao might fill the gaps between "real work" looking at the feasibility of implementing one of these things. If it was easy (and cheap) to implement, he'd whip it out and check it in.

(emphasis mine) Chad also mentions the potential pitfalls in such an approach:

• You waste time and money if the functionality was not needed
• You increase complexity of the code base and make "it less resilient to change" if your code forces "the system down a particular architectural path."
• You could unintentionally make the application "less functional or desirable to the customer."

Honestly, I'd caution against using this advice unless you are in one of the following situations:

1. You've known the feature-requester long enough that you can pick up on things he's asking for, but hasn't yet asked for. I think you should be really close in this situation. How can you predict otherwise?
2. There is obviously something missing from the spec, and you have enough experience with similar systems to know it is missing. This might be something like "We need a login system." You can probably safely assume they'll need a way to log out as well, and perhaps even "I forgot my password" functionality.
   
   The logout functionality I'd almost always toss in (unless requested otherwise). However, even on the "forgot password" feature, I'd consider a couple of things. First, do I know the customer well enough that we've done another application for them and they wanted it? Second, is the budget big enough to where I know they won't be upset if I implement it?

There could be more, but that's what my brain thought of this morning. Of course, in many cases it's just better to ask first.

What do you think?

How is it that an application of similar scope to those we spend weeks working on in the office is going to get finished in a single weekend?

We've all seen projects take weeks when they could be measured in days. So what gives? The answer, of course, is that we aren't accustomed to doing it right now. Stop putting off tasks. Just do them.

To help meet that goal and create race conditions, I like to timebox my daily tasks. From 5:30 to 6:15 I read my email do my morning blog reading. Then I take 15 minutes and enjoy a cold Red Bull. After that, I might work on Project A for 3 hours, then read email for 15 minutes. I've got half a days work done before most people get to the office. After that, I might switch to Project B for three more hours, and so on.

To keep track of what I should be working on and give myself pop-up reminders that it's time to change tasks, I've been using Apple's iCal, and it works pretty well. My only problem is that as I need to work more often in Windows, I'm not using it as much, and particularly this week my productivity has been way down. (I admit, the impending holiday may have something to do with that as well.) However, FedEx just dropped off VMWare Fusion, so hopefully I won't need to boot into Windows anymore and the problem will be solved. My only complaint against iCal itself is that I wish I didn't have to set up an email address in the mail client for it to send me an email - that's just annoying.

If you're not on a Mac, Google Calendar would work (except you're not getting the popup reminders). Even just spending 15 minutes before you leave work to plan the next day, and writing it on the whiteboard or some sticky-notes would likely be a major improvement for your work-day, and might even be better than a technology-based solution.

How have you made it easier on yourself to do it right now?

What can we do to help them get over this irrational behavior? If they continuously request those trivial changes and never go live, the project has failed. Do you think they will blame themselves, their ideas, and their actions? No, they will blame you, and find someone else to work with next time. So you may have been paid for your time, but it still impacts you negatively.

Don't get me wrong - sometimes there are good reasons to wait to release a product or service. Sometimes, you don't need to DIFN. However, the fear that your customers won't know to look under "output devices" to find a subcategory of "printers" is probably not on that list of reasons. Someone has been using a product to great advantage for many years and you want to "wait until you finish the last bit" to sell it as a whole to others - also probably not on that list. You want the login on the left hand side instead of the right?

After a week of such changes, it's one thing. Six months? GMAFB.

Perhaps you'd have been better off letting your customer's use it to see if they got confused, preferred blue links to red ones, or even happened upon an idea to make the application flow better.

So what does make the "OK to wait"-list? The fear of underwhelming an audience with your unfinished product would, especially if you're get to show them exactly one time. I can't think of much else that does. Can you?

So the point is that you need to get over the fear of success. Stop snatching defeat from the jaws of victory. Let a good thing or two happen. Help your customer's get past their fears.

Changing ourselves to recognize that fear and ignore it is something we can all do. Looking at our customer's excuses to keep the product in the warehouse from a fear-of-success angle might provide a way to relate to them instead of scoffing at their incessant requests for frivolity.

Success is staring you in the face. All you have to do is stick your hand out and embrace hers. Why do you turn and run away?

I'm exploring this space for the first time. Obviously, I have a lot of questions and very few answers. If you've got either of them, let me know in the comments - it's always appreciated.

My advice is to do it by the book, get good at the practices, then do as you will. Many people want to skip to step three. How do they know?

Similarly, part of code practice involves studying other people's code.

Doing so is good to teach you new tricks and things to avoid. But as Chad also mentions, it also exposes you to projects you might not have otherwise known about - giving you the option in the future to reuse it instead of writing your own version if your application requires it.

Two books I bought a few years ago might have been a good start to doing this type of thing: Mmurtl V1.0: How to Develop Your Own 32 bit OS and Linux Core Kernel Commentary. Sadly, I never did read them, and no telling where they are at now.

But not having those books won't stop me from reading source code - I plan to start that as part of my weekly practice sessions. It fits so well with one of the things I'm most interested in - improving the design of my own applications. You can say you don't run into trouble and therefore, your design is good, but how would you know until you've gone back to it after not looking at it for a year? You need something to compare it to, and I'm not convinced a UML diagram will suffice.

On top of that, if I'm lucky I'll gain some insight into my questions about how people go about designing algorithms. (Do you have answers?)

In the end, Chad gives two action items to follow up on:

1. Pick a project to read, make notes, and "outline the good and the bad." Use that experience to publish a critique of the project and it's code.
2. Start a study group to dissect and learn from code.

I'd like to start reading other source code, but I'm not sure when I'll publish a critique of it. On top of that, one of the things I'd like to do in the code dojo is dissect other people's code, even if I already find it helpful to analyze our own.

When you look at code, do you do it with a critical eye?

Preproject Considerations
Most of our business comes through referrals or new projects from existing customers. Out of those, we try only to accept referrals or repeat business from the "good clients," believing their friends will be similarly low maintenance, high value, and most importantly, great to work with.

We have tried the RFP circuit in the past, and recently considered going at it again. However, after a review of our experiences with it, we felt that unless you are the cause of the RFP being initiated, you have a subatomically small chance of being selected for the project (we've been on both ends of that one). Since it typically takes incredible effort to craft a response, it just seems like a waste of hours to pursue.

On the other hand, we are considering creating a default template and using minimal customization to put out for future RFPs, and even then, only considering ones that have a very detailed scope, to minimize our effort on the proposal even further.

We're also trying to move ourselves into the repeatable solutions space - something that really takes the cheap manufacturing ability we have in software - copying bits from one piece of hardware storage to another - and puts it to good use.

Finally, I'm very interested to hear how some of you in the small software business world bring in business. I know we're technically competitors and all, but really, how can you compete with this?

The Software Development Life Cycle
I won't bother you by giving a "phase" by phase analysis here. Part of that is because I'm not sure if we do all the phases, or if we're just so flexible and have such short iterations the phases seem to bleed together. (Nor do I want to spend the time to figure out which category what each thing belongs in.) Depending on the project, it could be either. Instead, I'll bore you with what we do pretty much every time:

At the start of a project, we sit down with client and take requirements. There's nothing fancy here. I'm the coder and I get involved - we've found that it's a ridiculous waste of time to pass my questions through a mediator and wait two weeks to get an answer. Instead, we take some paper or cards and pen, and dry erase markers for the whiteboard. We talk through of what the system should do at a high level, and make notes of it.

We try to list every feature in terms of the users who will perform it and it's reason for existence. If that's unknown, at least we know the feature, even if we don't know who will get to use it or why it's needed. All of this basically gives us our "use cases," without a lot of the formality.

I should also note that, we also do the formal bit if the need is there, or if the client wants to work that way. But those meetings can easily get boring, and when no one wants to be there, it's not an incredibly productive environment. If we're talking about doing the project in Rails or ColdFusion, it often takes me longer to write a use case than it would to implement the feature and show it to the client for feedback, so you can see why it might be more productive to skip the formality in cases that don't require it.

After we get a list of all the features we can think of, I'll get some rough estimates of points (not hours) of each feature to the client, to give them an idea of the relative costs for each feature. If there is a feature which is something fairly unrelated to anything we've had experience with, we give it the maximum score, or change it to an "investigate point cost," which would be the points we'd need to expend to do some research to get a better estimate of relative effort.

Armed with that knowledge, they can then give me a prioritized list of the features they'd like to see by next Friday when I ask them to pick X number of points for us to work on in the next week. Then we'll discuss in more detail those features they've chosen, to get a better idea of exactly what it is they're asking for.

We repeat that each iteration, adjusting the X number of points the client gets to choose based on what was actually accomplished the previous iteration - if there was spare time, they get a few more points. If we didn't finish, those go on the backlog and the client has fewer points to spend. Normally, we don't have the need for face to face meetings after the initial one, but I prefer to have them if we can. We're just not religious about it.

Whiteboards at this meeting are particularly useful, as most ideas can be illustrated quite quickly, have their picture taken, and be erased when no longer needed. Plus, it lets everyone get involved when we start prioritizing. Notecards are also nice as they swap places with each other with incredible ease.

Within each iteration, we start working immediately. Most of the time, we have one week iterations, unless there are a couple of projects going on - then we'll go on two week iterations, alternating between clients. If the project is relatively stable, we might even do daily releases. On top of that, we'll interface with client daily if they are available that frequently, and if there is something to show.

If the project size warrants it, we (or I) track our progress in consuming points on a burndown chart. This would typically be for anything a month or longer. If you'll be mostly done with a project in a week, I don't see the point in coming up with one of these. You can set up a spreadsheet to do all the calculations and graphing for you, and in doing so you can get a good idea of when the project will actually be finished, not just some random date you pull out of the air.



Another thing I try to be adamant about is insisting the client start using the product as soon as it provides some value. This is better for everyone involved. The client can realize ROI sooner and feedback is richer. Without it, the code is not flexed as much. Nor do you get to see what parts work to ease the workload and which go against it as early in the product's life, and that makes changes more difficult. For us, the typical client has been willing to do this, and projects seem to devolve into disaster more readily when they don't.

Finally, every morning we have our daily stand-up meeting. Our company is small enough so that we can talk about company-wide stuff, not just individual projects. Each attendee answers three questions:

1. What did you do yesterday?
2. What are you going to do today?
3. What is holding you back

The meeting is a time-conscious way (15 minutes - you stand so you don't get comfortable) to keep us communicating. Just as importantly, it keeps us accountable to each other, focused on setting goals and getting things done, and removing obstacles that get in our way.

On the code side of things, I try to have unit tests and integration tests for mostly everything. I don't have automated tests for things like games and user interfaces. I haven't seen much detriment from doing it this way, and the tradeoff for learning how to do it doesn't seem worth it at the moment.

I would like to learn how to do it properly and make a more informed decision though. That will likely come when time is not so rare for me. Perhaps when I'm finished with school I'll spend that free time learning the strategies for testing such elements.

Luckily, when I'm working on a ColdFusion project, cfrails is pretty well tested so I get to skip a lot of tests I might otherwise need to write.

By the same token, I don't normally unit test one-off scripts, unless there are obvious test cases I can meet or before doing a final version that would actually change something.

I don't know how to do it in CF, but when I've use continuous integration tools for Java projects it has been helpful. If you have good tests, the CI server will report when someone checks in code that breaks the tests. This means bad code gets checked in less often. If you don't have the tests to back it up, at least you'll feel comfortable knowing the project builds successfully.

For maintenance, we normally don't worry about using a project management tool to track issue. Bugs are fixed as they are reported - show stoppers immediately, less important within the day, and things deemed slight annoyances might take a couple of days. I'd like to formalize our response into an actual policy, though.

Similarly, new requests are typically handled within a couple of days if they are small and I'm not too busy - otherwise I'll give an estimate as to when I can have it done.

With bugs in particular, they are so rare and few in number that I could probably track them in my head. Nevertheless, I mark an email with my "Action Required" tag, and try my best to keep that folder very small. Right now I've overcommitted myself and the folder isn't empty, but there was a time recently that it remained empty on most nights.

In any event, I normally only use project management tools for very large projects or those I inherited for some reason or another.

Summary
If you're a practitioner, you can tell the ideas above are heavily influenced by (when not directly part of) Scrum and Extreme Programming. I wouldn't call what we're doing by either of their names. If you're not familiar with the ideas and they interest you, now you know where to look.

Where would we like to go from here?
One thing that sticks out immediately is client-driven automated testing with Selenium or FIT. I'd also like to work for several months on a team that does it all and does it right, mostly to learn how I might better apply things I've learned, heard of, or yet to be exposed to. What else? That will have to be the subject of another post, as this one's turned into a book.

Thoughts, questions, comments, and criticisms are always welcome below.

1. JetBrains' IntelliJ IDEA: An awesome IDE for Java. So great, I don't mind spending the $249 (US) and using it over the free Eclipse. The Ruby plugin is not too shabby either, the license for your copy is good for your OSX and Windows installations, and you can try it free for 30 days. Martin Fowler thinks IntelliJ changed the IDE landscape. If you work in .NET, they also have ReSharper, which I plan to purchase very soon. Now if only we could get a ColdFusion plugin for IntelliJ, I'd love it even more.
   
   
2. Programming Ruby, Second Edition: What many in the Ruby community consider to be Ruby's Bible. You can lower the barrier of entry for your favorite programmer to using Ruby, certainly one of the funner languages a lot of people are loving to program in lately. Sometimes, I sit and think about things to program just so I can do it in Ruby.
   
   If they've already got that, I always like books as gifts. Some of my favorites from this year have been: Code Complete 2, Agile Software Development: Principles, Patterns, and Practices which has a great section on object oriented design principles, and of course, My Job Went to India. I have a slew of books I've yet to read this year that I got from last Christmas (and birthday), so I'll have to list those next year.
   
   
3. Xbox 360 and a subscription to XNA Creator's Club (through Xbox Live Marketplace - $99 anually) so they can deploy their games to their new Xbox. This is without a doubt the thing I'd want most, since I got into this whole programming thing because I was interested in making games. You can point them to the getting started page, and they could make games for the PC for free, using XNA (they'll need that page to get started anyway, even if you get them the 360 and Creator's Club membership to deploy to the Xbox).
   
   
4. MacBook Pro and pay for the extra pixels. I love mine - so much so, that I intend to marry it. (Ok, not that much, but I have been enjoying it.) The extra pixels make the screen almost as wide as two, and if you can get them an extra monitor I'd do that too. I've moved over to using this as my sole computer for development, and don't bother with the desktops at work or home anymore, except on rare occasions. You can run Windows on it, and the virtual machines are getting really good so that you ought not have to even reboot to use either operating system.
   
   Even if you don't want to get them the MacBook, a second or third monitor should be met with enthusiasm.
   
   
5. A Vacation: Programmers are notoriously working long hours and suffering burnout, so we often need to take a little break from the computer screen. I like SkyAuction because all the vacations are package deals, there's often a good variety to choose from (many different countries), most of the time you can find a very good price, and usually the dates are flexible within a certain time frame, so you don't have to commit right away to a certain date.

Happy Thanksgiving to those celebrating it, and thanks to all you who read and comment and set me straight when I'm wrong - not just here but in the community at large. I do appreciate it.

Do you have any ideas you'd like to share (or ones you'd like to strike from this list)?

• Physical/coordination: Visiting "the dusty corners of your primary programming language," such as deep exploration of regular expressions, tools, and APIs you rarely (or never) get a chance to use at your day job. I'd put learning other languages here, and experimenting with new constructs and paradigms, like you can win an iPod Nano for doing. You may not use it often, but when you need to, you'll be prepared. On the other hand, you may find something that used to take you hours can be done in one line of code - it's built right into the language.
  
  
• Sight reading: If you can sight-read code, how much faster would you be at finding and diagnosing problems, or adding new features, just by having the ability to understand the structure of an application instantly? Chad recommends going to the to-do list of an open source application, deciding on a feature to implement or bug to fix, and then going through the source to find out where it needs to go. Impose time constraints on yourself, and rotate through many different projects (and languages), and you'll get faster at "sight reading" code. You don't even need to implement it - just finding the place to put it would be enough (but it would be even better if you did!).
  
  
• Improvisation: Chad defines improvisation as "taking some structure or constraint and creating something new, on the fly, on top of that structure." One such example he described was

  recovering lost data by manually replaying packets over a wireless network from a binary log file. No body meant for you to do these things, especially not in the heat of the moment. [But] that kind of sharp and quick programming ability can be like a magical power when wielded at the right time.

Of the three, I really like his ideas on practicing improvisation: "Pick a simple program, and try to write it with [self-imposed] constraints." One example is printing the lyrics to 99 Bottles of Beer on the Wall "without doing any variable assignments." Or golfing. I'm sure you can think of others (and I plan to).

I haven't done as good a job at practicing as I'd like to, so I'm going to resolve to sit down weekly and just have some practice time, stressing the points above. I won't be too ambitious though - I've already over-committed myself for the rest of this year. But as my early New Year's Resolution, I'll plan on blogging my weekly experience in regularly scheduled practice, like Scott Hanselman does in his series, The Weekly Source Code.

Anyone want to lend some moral support and start practicing too? We could be like virtual workout partners, flexing our coding muscles.

Note: I didn't do a good job of showing it in the article itself, but all the quotes there are from Chad Fowler.

Unfortunately, I quickly found out that the one professor I wanted as an advisor would be leaving soon and was not taking any new students. But I didn't let that stop me. Sure, a formal relationship with a mentor is nice, but as Chad mentions in the book, you can have mentors who don't even know they are filling that role for you.

So I started becoming involved online - asking and answering questions in topics of interest to me. Answering questions is particularly beneficial, because you get to throw ideas into the arena and see if your expert "mentors" will disagree with you and correct you when you are wrong. In fact, there's nothing on this blog I enjoy more than when someone disagrees with me in a comment* (with substance, anyway). On the other hand, when you are right you learn that you are right and you reinforce that knowledge.

I also made it a point to sit in the front row (or close to it) of every class and ask questions to aid in my understanding of the subject matter. I started visiting conferences and talks and user group meetings to learn from other developers when time permits. Some friends and I organized the UH Code Dojo in an effort to have mentors and be mentors. Another friend or two are helping me progress in .NET faster than I would alone and we're throwing around the idea of forming a game development meet-up group. I started reading blogs and participating in comments on various topics on a regular basis, rather than just when I needed to find information on a particular problem. Several blogs cover languages or topics I rarely use. Some cover things I've yet to use at all. Finally, I'm planning on going deeper into bioinformatics and game development with the advanced courses next semester, where the one-on-one time with the professor is much more like a mentoring relationship.

Notice that, excepting the Code Dojo, where our aims to be a mentor and be mentored are explicit, nothing in the previous paragraph requires those people to know they are filling that role for me (until they read this, I suppose).

If anyone wants to be my mentor, I can pay you with a heartfelt "Thanks!" And if you need a mentor, don't hesitate to contact me. I'm always glad to help when that precious combination of time and knowledge allows for it.

Do you have mentoring relationships with anyone, or any group? How does it work for you?

*: I'm starting to think everything I say is correct because I haven't had many disagreements lately. Perhaps I need to start saying stupid things I know are wrong just to see if you all are paying attention. I'll be a troll on my own blog.

Being a good developer means not relying on your "server guy" to set everything up for you. Be a master of source control, testing, and of setting up your own development tools: the IDE, outside references or the build path, and the virtual machine (or whatever runs your code).

Learn how to make ColdFusion work with your database. Figure out how to install and run Rails - don't rely on it being preinstalled on Leopard.

For quite some time in college I was afraid of using the command line to compile my programs - I just wrote them in Windows using Dev C++ and turned them in, blindly hoping they would compile and work correctly for the person grading my program on Unix.

For God's sake, learn how to compile your own programs, even if modern IDEs do it onSave().

I hate to say it, but you're in the wrong line-of-work if you are constantly asking for fish. Technologies change too quickly to ask for help every time you run into a roadblock. The problem is magnified tenfold if you have to ask several times to accomplish the same task.

On another note, Chad mentions code-by-wizardry as being particularly painful:

A[n] ... easy way to get lazy is to use a lot of wizards that generate code for you. This is particularly prevalent in the world of Windows development where, to Microsoft's credit, the development tools make a lot of tasks really easy. The downside is that many Windows developers have no idea how their code really works. (page 50, emphasis mine)

I can attest to that. You know that main class that processes all the callbacks in a typical Windows program? I didn't either. Consequently, my first several forays into programming for Windows resulted in disaster. If I could find that code, I'd love to post it for inspection, so you could marvel at how Button1 did something for TextField2 and all of it somehow worked in one GodClass. The magnificence of the horror led to nightmares for me recently as I discovered the XNA framework. The wizards are there to make your life easy - not to be a replacement for knowledge and thought. You still need to understand what they are doing for you.

The point is that you have to learn. Don't be afraid to ask, but when you ask, make sure there is a purpose behind it. If you teach yourself to learn, and you learn everything you need to know, you'll be in good shape. But, to end with some advice from an old professor of mine, be honest about what you know. Don't be afraid to admit your shortcomings - instead, use it as a chance to learn, not as a chance to have someone else do it for you.

Don't do it that way is the advice from MJWTI this week.

In particular, I want to share one passage that resonated with me:

Somehow, as an industry, we fool ourselves into thinking market leader is the same thing as standard. So, to some people, it seems rational to make another company's product a part of their identities. Even worse, some base their entire careers around non-market-leading products -- at least until their careers fail so miserably that they have no choice but to rethink this losing strategy.

Let me repeat that: some people base their entire careers around non-market-leading products.

That sounds just about where I was 18 months ago. Today, I cannot imagine basing my career around a product, much less insignificant ones. I try to relate everything to myself in terms of ideas, and I try to regularly experiment with the unfamiliar. Even if I were not able to do some of it at work, it would be well worth the effort of spending a little time at home to do that.

Moving around at the whim of others. You assert no control over your own safety. If you were dropped, what would you do?

Have you felt that way? Do you still?

Chad mentions a measure he used to assess a job candidate's depth of knowledge in Java: a question of how to make the JVM crash.

I'm definitely lacking in this regard. I've got a pretty good handle on Java, Ruby, and ColdFusion. I've done a small amount of work in .NET and have been adding to that recently. I can certainly write a program that will crash - but can I write one to crash the virtual machine (or CLR)?

I can relunctantly write small programs in C/C++, but I'm unlikely to have the patience to trace through a large program for fun. I might even still be able to figure out some assembly language if you gave me enough time. Certainly in these lower level items it's not hard to find a way to crash. It's probably harder to avoid it, in fact.

In ColdFusion, I've crashed the CF Server by simply writing recursive templates (those that cfinclude themselves). (However, I don't know if that still works.) In Java and .NET, I wouldn't know where to start. What about crashing a browser with JavaScript?

So Chad mentions that you should know the internals of JVM and CLR. I should know how JavaScript works in the browser and not just how to getElementById(). With that in mind, these things are going on the to-learn list - the goal being to find a way to crash each of them.

Ideas?

Towards the end of the chapter, Chad tells us about his early days in IT:

What first amazed me most when I entered the information technology field was that many well-educated programmers (maybe most) didn't know the first thing about how to set up the systems they used for development and deployment. I worked with developers who couldn't even install an operating system on a PC if you asked them to, much less set up and application server on which to deploy their applications.

After reading that, I thought to myself, "That's me." Rather than wallow in self-pity, I decided to do something about it.

Where I used to ask "our server guy" (that's his official name) to do something, I started asking him how to do it. ButI didn't immediately start there - I started trying to figure it out on my own before going to him for help (à la Mr. Raymond's famous guide). Now I don't need help in setting up virtual directories or web sites or my development environment (yes, I was that bad).

Instead of being helpless, I set up Rails, installed Linux and fixed up dual widescreen monitors, set up Subversion, set up my own development environments in general, and played with ANTLR, among a slew of other things past, present, and planned for the future (on my TO-LEARN list).

Doing things like I mention above is not impressive. Certainly things like that aren't hard to do. But doing them helps you get over your fear of new technology and take responsibility for your own improvement.

The chapter ends with advice to "list the dimensions on which you may or may not be generalizing your knowledge and abilities" and to do something about it. There are an "infinite number" of aspects for which you could do it, but Chad limits his discussion to five: "Rung on the career ladder, Platform/OS, Code vs. data, Systems vs. applications, [and] Business vs. IT."

I've got a long way to go, but I'm slowly getting to where I want to be. Are you doing anything?

As I said in the last post about this book, I used to be that developer. Since then, I've improved myself considerably in Java and learned a great deal about Ruby, among other things.

But asking "what's your new language this year?" misses the point. The big shift comes when you accept responsibility for your own improvement. Once you've done that, instead of feeling threatened by new (to you) technologies, you start to embrace them.

Now, instead of avoiding projects in unfamiliar territory, I'm asking for them. Instead of laying down to be steamrolled by something I've yet to try, I take at least a few minutes to familiarize myself with it, like I did recently with ANTLR. When I've got a bit of extra time on my hands, I'll go all out and even do something useful with it.

Go explore. Now.

That sounds incredibly unlike me now. Although the change was occurring before I read his book (as evidenced by the fact that I was reading it in the first place), it certainly helped accelerate things.

(Let me also say I feel weird posting a link to the book each time I write one of these, but I don't want someone new to come along and think "WTF's he on about?" So for all you regulars, please ignore what must seem like link spam for the greater good of improving oneself: I'm not a PragProg salesman or affiliated with them in any way. Though I am an affiliate with Amazon, I don't get any special consideration for promoting this book out of all the other things I could be writing about.)

Anyway, Chad suggests making "a list of early, middle, and late adoption technologies" (page 23). Then, note the one's you're strong in, ones you have some experience in, and some you have no experience in. Try to notice any pattern there. And finally, "are there any technologies around the far edges that you have some special interest in?" Those are the high risk/high reward type cases where there is more money to be made. The middle has many more jobs, but also much more competition from other programmers.

So here's a small list I made (from early adoption to late adoption). A + marks technologies I'm fairly strong in while a - is just some experience. I 'm trying to be honest with myself, so call me out if you think I've got something wrong:

Early adoption: Lisp(-), Haskell, Erlang, Ruby(+), JavaScript(+)

Middle adoption: SQL(+), Python, Perl, ColdFusion(+), PHP(-), ASP.NET(-), C#(-), Java(+), .NET(in general)(-)

Late adoption: ASP(-), JSP(+), ASM, Visual C++(-), COBOL

I put Lisp in early adoption because I could foresee it becoming big at some point. Probably not, but I don't think its mainstream or in its sunset years either. Similarly, I think JavaScript while abundantly adopted is only done for simple web scripting. I see its importance rising.

I'm not sure where CF belongs, honestly. Certainly not early adoption. It's in the middle somewhere, but I don't know how early in the middle or how late. I'm tending later. For Java, I put it near late adoption because I think its importance as a language is diminishing, though its importance as a platform will remain steady.

I'm not sure where to put PHP either honestly. I almost went with late adoption because I can't foresee myself ever looking for a job doing PHP. But that's just me. I certainly don't think its importance is on the rise, however. Of course, I don't think that about CF either, given prevailing attitudes.

That's just a few large things- a lot related to web development (since that's what I'm most familiar with). I'm also having trouble thinking of technologies I have no experience in whatsoever. There are tons, to be sure, I'm just not finding any when it comes to the language level of granularity. What important languages have I missed? I know I missed SmallTalk, but I don't know whether to put that in early or late adoption. At the moment it belongs in late, but will its importance rise?

Anyway, what does your list look like? What technologies are missing from mine and where would you put them on the curve?

Working for a tiny consulting company, I get the benefit of being close to all the business decisions, but not in many specialized domains. However, since I made the decision to stop being a "code robot" (Chad's term), I've always taken the opportunity to talk with clients or meet them for lunch to discuss their domains. Even more recently, a couple of us here have taken to reading trade publications related to a product we're building.

Doing so helps you understand why some of those "crazy" requests are made, and what you can do to make them work in the system while still accomplishing the client's goals. And things just seem to work better that way. Nowadays, I'm no longer getting any "that's a nice system, but it's not what I wanted" comments due to keeping myself stuck in a walled garden. Instead, I'm building software customers want and will use. And the purely selfish benefit: I'm adding to my value as an employee or contractor in those domains.

As an aside, last week I was on vacation, so that's why you didn't see this then. I'll try to make up for it and post two this week.

So are you a code monkey? Are you trying to evolve into a code human?

In the first nine chapters, Chad tells us how to choose the right market. So for my first week, he addresses supply and demand: first we want to search jobs in our home country, as well as those available offshore. Compare the results and highlight skills in demand in your home country that nobody (or very few people) offshore is offering.

Then, you just need to become good at those technologies that are in demand but aren't yet available offshore (or in high supply). This is simple economics.

To get a head start, you might want to watch the alpha geeks and see what they're doing, but you can probably afford to start a little farther along on the curve.

Sounds easy enough. So, start googling. Better yet, why doesn't someone create a service that performs this search and analysis for us?